6장. RAG와 에이전트

출처: 『AI 엔지니어링』(Chip Huyen, 한국어판), 6장 pp. 305–363

모델이 작업을 처리하려면 수행 방법에 대한 지시와 필요한 정보, 이 두 가지가 모두 있어야 한다. 특정 애플리케이션에서 지시는 모든 질의에 공통으로 쓰이지만, 컨텍스트는 질의마다 달라진다. RAG는 외부 데이터에서 질의별 컨텍스트를 동적으로 구성하고, 에이전트는 도구를 통해 환경과 상호작용하며 복잡한 작업을 자동화한다. 두 패턴 모두 모델을 수정하지 않고 입력만으로 모델의 능력을 크게 확장한다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• RAG와 에이전트의 관계를 설명하고 각각의 작동 원리를 이해한다.
• 용어 기반 검색과 임베딩 기반 검색을 비교하고 상황별 최적 검색 방식을 선택한다.
• 청킹 전략, 재순위화, 질의 재작성, 컨텍스트 검색 등 검색 최적화 기법을 적용한다.
• ReAct와 성찰 메커니즘으로 에이전트의 계획과 오류 수정 흐름을 설계한다.
• 에이전트의 실패 유형(계획 수립·도구·효율성)을 진단하고 개선 방안을 제시한다.
• 메모리 계층(내부 지식·단기·장기)을 구분하고 세션 간 정보 관리 전략을 설계한다.

전체 흐름도

이 장의 핵심은 "외부 데이터를 동적으로 끌어와 생성 품질을 높이고, 도구로 환경에 행동하는 에이전트로 확장한다" 는 두 단계 확장 구조다.

[ 사용자 질의 ]
      │
      ▼
[ 질의 전처리 ]
      │  모호한 대화 맥락 → 질의 재작성(Query Rewriting)
      │  멀티 질의 → 여러 검색 결과 병합
      │
      ▼
[ 검색기 (Retriever) ]
      │
      ├─ 용어 기반 검색 (TF-IDF / BM25)        ← 빠름·저렴·단어 형태 기반
      ├─ 임베딩 기반 검색 (Semantic Search)     ← 의미 기반·벡터 DB
      └─ 하이브리드 검색 (RRF 결합)             ← 두 방법 조합 (운영 환경 권장)
      │
      │  재순위화(Reranking)으로 최종 상위 k 청크 선택
      │
      ▼
[ 컨텍스트 구성 ]
      │  사용자 프롬프트 + 검색된 청크(들) + 메타데이터
      │
      ▼
[ 생성 모델 (LLM) ]
      │  내부 지식 + 외부 컨텍스트 결합
      ▼
[ 응답 ]

            ─────  여기까지가 RAG 파이프라인  ─────

[ 에이전트 루프 ]  ← RAG를 하나의 도구로 내장한 확장 구조

      사용자 작업
          │
          ▼
      [ 계획 수립 (Planning) ]
          │  계획 생성 → (검증) → 실행
          │  ReAct: 생각 → 행동 → 관찰 반복
          │  성찰(Reflexion): 단계별 자기 평가·오류 수정
          │
          ▼
      [ 도구 선택 및 호출 (함수 호출) ]
          │
          ├─ 지식 증강 도구  (RAG 검색 / 웹 브라우징 / 내부 DB / 재고 API)
          ├─ 능력 확장 도구  (계산기 / 코드 인터프리터 / 번역기 / 캘린더)
          └─ 쓰기 행동 도구  (이메일 발송 / DB 수정 / 파일 조작)
          │
          ▼
      [ 관찰 (환경 피드백) ]
          │
          └─ 작업 미완료 → 성찰 후 계획 수립으로 되돌아감
          └─ 작업 완료 → 응답 반환

[ 메모리 시스템 ]  ← 정보 과부하 관리 및 세션 간 지속성 확보
      ├─ 내부 지식  (모델 가중치, 영구)
      ├─ 단기 메모리  (컨텍스트 윈도우, 세션 내)
      └─ 장기 메모리  (외부 저장소·RAG, 영구)

0. 사전 필수 용어

참고 — 이 장을 이해하려면 임베딩과 벡터 유사도 개념이 필수다. 3장(임베딩)을 먼저 읽으면 이해가 크게 쉬워진다.

• RAG(Retrieval-Augmented Generation, 검색 증강 생성) — 외부 메모리 소스에서 질의와 관련된 정보를 검색한 뒤 그 정보로 컨텍스트를 보강해 응답을 생성하는 패턴. 각 질의에 특화된 컨텍스트를 만들어낸다는 점에서 전통적 ML의 특성 공학(피처 엔지니어링)과 목적이 동일하다.
• 임베딩(Embedding) — 텍스트나 이미지 같은 데이터를 의미적 특성을 보존하는 고밀도 숫자 벡터로 변환한 표현. 의미가 비슷한 데이터는 벡터 공간에서 가까이 위치한다.
• 벡터 데이터베이스(Vector DB) — 임베딩 벡터를 저장하고 빠른 최근접 이웃 검색을 제공하는 데이터베이스. RAG 시스템에서 임베딩 기반 검색의 핵심 인프라다.
• 코사인 유사도(Cosine Similarity) — 두 벡터 간의 각도를 기반으로 유사도를 측정하는 지표. 값이 1에 가까울수록 유사하다. 임베딩 기반 검색에서 질의와 문서의 관련성 점수를 계산하는 데 자주 쓰인다.
• 에이전트(Agent) — 자신의 환경을 인식하고 그 환경에서 행동할 수 있는 시스템. AI 에이전트에서 AI는 두뇌 역할을 하며 도구를 활용해 작업을 수행한다. 작동하는 환경과 수행할 수 있는 행동들로 정의된다.
• 함수 호출(Function Calling) — 모델이 사용할 도구와 파라미터를 구조화된 형식으로 자동 생성하는 기능. 에이전트 도구 사용의 기술적 구현 방식이다.
• ANN(Approximate Nearest Neighbor, 근사 최근접 이웃) — 정확한 k-NN 대신 속도와 정확도를 균형 잡는 알고리즘. 수백만 개 이상 벡터 실시간 검색 시 필수다.

1. RAG란 무엇인가

RAG는 외부 메모리 소스에서 관련 정보를 검색하여 모델의 생성을 향상시키는 기술이다. 외부 메모리 소스는 내부 데이터베이스, 사용자의 이전 채팅 세션, 또는 인터넷이 될 수 있다.

역사. 검색 후 생성(retrieve-then-generate) 패턴은 Chen 등(2017)의 연구에서 처음 소개됐다. 이 연구에서 시스템은 먼저 질의와 가장 관련성이 높은 5개의 위키피디아 페이지를 검색한 다음 모델이 이 페이지 정보를 사용해 응답을 생성했다. RAG라는 용어는 Lewis 등(2020)의 논문에서 처음 사용됐다. 이 논문은 가용한 지식 전부를 모델에 직접 입력하기 어려운 지식 집약적 작업을 해결하기 위한 방법이었다.

RAG의 핵심 가치. RAG는 모든 질의에 동일한 컨텍스트를 사용하지 않고, 각 질의에 특화된 컨텍스트를 만들어내는 기술로 볼 수 있다. 특정 사용자에 관한 질의가 들어올 때만 해당 사용자의 데이터를 컨텍스트에 포함하면 되므로 사용자 데이터 관리에도 유용하다.

RAG가 롱 컨텍스트로 대체되지 않는 이유. 많은 사람이 충분히 긴 컨텍스트로 RAG의 필요성을 없앨 수 있을 거라 생각하지만, 그렇지 않다. 첫째, 데이터는 계속 증가하기 때문에 컨텍스트 길이가 아무리 늘어도 그보다 더 긴 컨텍스트가 필요한 애플리케이션이 생길 수밖에 없다(파킨슨의 법칙 유비). 둘째, 롱 컨텍스트를 처리할 수 있는 모델이 반드시 그 컨텍스트를 잘 활용하는 것은 아니다. 컨텍스트가 길수록 모델이 잘못된 부분에 집중할 가능성이 높아지며, 추가 토큰은 비용과 지연 시간을 증가시킨다. RAG는 가장 관련성 높은 정보만 사용해 입력 토큰 수를 줄이면서도 성능을 향상시킨다.

참고 — Anthropic은 지식 베이스가 200,000토큰(약 500페이지 분량) 미만이라면 RAG 없이 전체 지식 베이스를 프롬프트에 포함시켜도 된다고 조언한 바 있다. 지식 베이스 규모에 따라 RAG와 롱 컨텍스트를 선택하면 된다.

2. RAG 아키텍처

RAG 시스템은 두 가지 구성 요소로 이루어져 있다. 외부 메모리 소스에서 정보를 검색하는 검색기와 검색된 정보를 기반으로 응답을 생성하는 생성 모델이다. RAG 시스템의 성공은 검색기의 품질에 달려 있다.

검색기의 두 기능. 색인화(indexing)는 나중에 빠르게 검색할 수 있도록 데이터를 처리하는 작업이다. 질의(querying)는 관련 데이터를 검색하기 위해 시스템에 요청을 전송하는 과정이다. 데이터를 어떻게 색인화할지는 나중에 어떻게 검색하고 싶은지에 따라 달라진다.

작동 흐름. 문서는 10개의 토큰이나 100만 개의 토큰일 수 있으므로 문서 전체를 그냥 검색하면 컨텍스트가 지나치게 길어질 수 있다. 이를 방지하기 위해 각 문서를 더 관리하기 쉬운 청크(chunk)로 분할한다. 각 질의의 목표는 가장 관련성 높은 데이터 청크를 검색하는 것이다. 찾아낸 데이터 청크를 사용자 프롬프트와 합쳐 최종 프롬프트를 만들어 생성 모델에 입력한다.

참고 — 이 장에서는 문서와 청크를 모두 '문서'라고 부른다. 청크도 기술적으로는 하나의 문서로 볼 수 있기 때문이다. 이는 전통적인 NLP와 정보 검색(IR) 분야의 용어와 일치시키기 위함이다.

RAG 시스템 전체 파인튜닝. 원래 RAG 논문에서 Lewis 등은 검색기와 생성 모델을 함께 학습시켰다. 오늘날은 이미 만들어진 검색기와 생성 모델을 활용해 시스템을 구축하는 경우가 많다. 그러나 RAG 시스템 전체를 처음부터 끝까지 파인튜닝하면 성능이 훨씬 좋아질 수 있다.

3. 검색 알고리즘 — 용어 기반 vs 임베딩 기반

정보 검색은 100년이 넘은 오래된 개념이다. 검색은 주어진 질의에 대한 문서들의 관련성을 기준으로 순위를 매기는 방식으로 작동한다. 검색 알고리즘은 관련성 점수를 계산하는 방법에 따라 달라진다.

3.1 희소 vs 밀집 분류법

일반 문헌에서는 검색 알고리즘을 희소(sparse)와 밀집(dense) 범주로 나누지만, 이 책에서는 용어 기반과 임베딩 기반이라는 분류법을 사용한다. 희소 벡터란 대부분의 값이 0인 벡터다. SPLADE처럼 BERT 임베딩을 활용하지만 정규화를 통해 대부분의 값을 0으로 만드는 알고리즘은 희소-밀집 이분법으로는 잘못 분류될 수 있다. 용어 기반/임베딩 기반 분류법이 이런 오분류를 피할 수 있다.

3.2 용어 기반 검색(Term-Based Retrieval)

단어의 형태를 기반으로 관련성을 계산하는 방식으로, 어휘적 검색(lexical retrieval)이라고도 한다.

TF-IDF. 용어 빈도(TF: Term Frequency)와 역문서 빈도(IDF: Inverse Document Frequency)를 결합한 알고리즘이다. 용어가 특정 문서에 자주 등장할수록(TF 높음) 관련성이 높고, 전체 문서에서 드물게 등장할수록(IDF 높음) 그 용어가 더 중요하다. 수학적으로:

Score(D, Q) = Σ IDF(ti) × f(ti, D)
IDF(t) = log(N / C(t))   (N: 전체 문서 수, C(t): 용어 t를 포함하는 문서 수)

역색인(Inverted Index). 엘라스틱서치(Shay Banon, 2010)는 루씬을 기반으로 역색인 데이터 구조를 활용한다. 역색인은 용어를 문서로 매핑하는 사전이다. 용어 빈도와 문서 빈도 같은 추가 정보도 저장해 TF-IDF 점수 계산에 활용한다.

BM25. 오카피 BM25(Best Matching 25번째 세대)는 1980년대 로버트슨 등이 개발한 TF-IDF 개선판이다. 단순한 TF-IDF와 비교해 문서 길이를 고려해 용어 빈도 점수를 정규화한다. 긴 문서일수록 특정 용어를 포함할 가능성이 높기 때문이다. BM25와 변형(BM25+, BM25F)은 지금도 산업계에서 널리 사용되며, 임베딩 기반 검색과 비교할 때 중요한 기준점(베이스라인)이 된다.

토큰화 고려사항. 'hot dog'를 'hot'과 'dog'으로 나누면 원래 의미가 사라진다. 이를 해결하기 위해 자주 함께 등장하는 n-gram을 하나의 용어로 취급한다. 소문자 변환, 구두점 제거, 'the', 'and' 같은 불용어 제거도 필요하다.

용어 기반 검색의 한계. 단어 형태만 보기 때문에 의미적으로 유사한 문서를 찾지 못할 수 있다. '트랜스포머 아키텍처' 검색 시 AI 모델이 아닌 전기 장치나 영화 관련 문서가 나올 수 있다. 또한 데이터를 임베딩으로 변환하면 특정 오류 코드(예: EADDRNOTAVAIL (99))나 제품 이름 같은 키워드가 희석될 수 있다.

3.3 임베딩 기반 검색(Embedding-Based Retrieval)

문서의 의미가 질의와 얼마나 가까운지를 기준으로 순위를 매기는 방식으로, 의미 기반 검색(semantic retrieval) 또는 밀집 검색이라고도 한다.

색인화 과정. 원본 데이터 청크를 임베딩 벡터로 변환해 벡터 데이터베이스에 저장한다.

질의 과정(2단계). 1) 색인화에 사용된 것과 동일한 임베딩 모델을 사용해 질의를 임베딩으로 변환한다. 2) 벡터 데이터베이스에서 질의 임베딩과 가장 가까운 k개의 데이터 청크를 가져온다. k 값은 활용 사례, 생성 모델, 질의에 따라 달라진다.

벡터 검색 알고리즘. 벡터 검색은 최근접 이웃 검색 문제로 접근한다. k-NN은 정확하지만 모든 벡터와의 유사도를 계산해야 해 큰 데이터셋에서 느리다. 실무에서는 근사 최근접 이웃(ANN) 알고리즘을 사용한다.

대표적인 ANN 알고리즘: - LSH(지역 민감 해싱) — 유사한 벡터를 같은 버킷에 해싱. FAISS와 Annoy에 구현. - HNSW(계층적 탐색 가능 소규모 세계) — 다중 레이어 그래프 구조로 검색. FAISS, Milvus에 구현. - 제품 양자화(Product Quantization) — 벡터를 여러 하위 벡터로 분해해 저차원 표현. FAISS의 핵심 구성 요소. - IVF(역파일 색인) — K-평균 클러스터링으로 유사 벡터를 같은 클러스터로 묶음. - Annoy — 트리 기반 접근. 스포티파이가 오픈소스로 공개.

벡터 검색 솔루션은 버킷·트리·그래프로 벡터를 구성하며, 양자화(정밀도 낮춤)나 희소화로 연산 자원을 절약한다. ANN-벤치마크 사이트에서 재현율, QPS, 구축 시간, 색인 크기 네 가지 지표로 다양한 알고리즘을 비교한다.

비용 고려사항. 임베딩을 생성하는 데는 비용이 든다. 데이터가 자주 변경되어 임베딩을 자주 다시 만들어야 한다면 큰 문제가 될 수 있다. 기업이 벡터 데이터베이스에 쓰는 비용이 모델 API 비용의 5분의 1, 심지어 절반에 이르는 경우도 흔하다.

파인튜닝 가능성. 임베딩 모델과 검색기를 각각 따로 파인튜닝하거나, 둘을 함께 파인튜닝하거나, 생성 모델까지 포함해 전체적으로 파인튜닝할 수 있다.

3.4 하이브리드 검색

운영 환경의 검색 시스템은 보통 두 방법을 결합한 하이브리드 검색을 사용한다.

순차 결합(재순위화 패턴). 먼저 비용이 적게 드는 용어 기반 검색으로 후보군을 추려내고, 그 다음 더 정확하지만 비용이 많이 드는 임베딩 기반 검색으로 이 후보 중 최상의 결과를 찾는다.

앙상블 결합(RRF). 여러 검색기를 동시에 사용해 후보를 가져온 다음, 역순위 퓨전(RRF: Reciprocal Rank Fusion) 알고리즘으로 다양한 순위들을 하나로 결합해 최종 순위를 생성한다.

RRF 공식:

Score(D) = Σ 1 / (k + ri(D))
여기서 ri(D)는 검색기 i에 의한 문서 D의 순위, k는 상수(보통 60)

직관적으로, 1위 문서는 1/1=1, 2위 문서는 1/2=0.5의 점수를 받으며 모든 검색기에서 받은 점수의 합이 최종 점수다.

3.5 검색기 품질 평가

두 가지 핵심 지표: - 컨텍스트 정밀도(Context Precision) — 검색된 모든 문서 중에서 실제로 질의와 관련된 문서의 비율. 컨텍스트 관련성이라고도 한다. - 컨텍스트 재현율(Context Recall) — 질의와 관련된 모든 문서 중에서 실제로 검색된 문서의 비율.

운영 환경에서는 컨텍스트 재현율 계산이 어렵다(데이터베이스의 모든 문서에 관련성 주석이 필요). 순위가 중요할 때는 NDCG, MAP, MRR 같은 지표를 추가로 사용한다. 임베딩 기반 검색에서는 MTEB 벤치마크(Muennighoff et al., 2023)로 임베딩 품질도 평가한다.

검색 솔루션 평가 기준. 지원하는 검색 방식, 임베딩 모델·벡터 검색 알고리즘, 확장성, 색인화 시간, 질의 지연 시간, 가격 체계(저장량 기반 vs 요청 횟수 기반).

4. 검색 최적화 — 청킹·재순위화·질의 재작성·컨텍스트 검색

작업 특성에 따라 관련 문서가 검색될 가능성을 높이는 네 가지 전략이 있다.

4.1 청킹 전략(Chunking)

문서를 어떻게 색인화할지는 나중에 어떻게 검색할 것인지에 따라 결정된다. 청킹 전략은 검색 성능에 상당한 영향을 미친다.

고정 크기 분할. 가장 단순한 전략으로 문자·단어·문장·단락 단위로 동일한 길이의 청크로 나눈다. 예: 2,048자 또는 512단어 청크.

재귀적 분할. 최대 청크 크기에 들어올 때까지 점점 작은 단위(절 → 단락 → 문장)를 사용해 분할한다. 관련 내용이 임의로 끊길 가능성이 줄어든다.

문서 유형별 특화 분할. 다양한 프로그래밍 언어용 분할기, Q&A 문서의 질의-응답 쌍 분할, 중국어 텍스트 등 언어별 특화 분할이 있다.

겹침(Overlap). 청크 간 겹침을 두면 경계 정보가 최소한 하나의 청크에 포함되도록 보장한다. 예: 청크 크기 2,048자, 겹침 20자. 청크 크기는 생성 모델의 최대 컨텍스트 길이를 넘지 않아야 한다.

토큰 단위 청킹. 생성 모델의 토크나이저 기준으로 분할한다. 이후 모델 작업이 수월해지지만, 다른 토크나이저를 사용하는 모델로 바꾸면 데이터를 처음부터 다시 색인화해야 한다.

청크 크기 트레이드오프. 작은 청크는 더 다양한 정보를 담을 수 있어 모델에 더 넓은 범위의 정보를 제공하지만, 중요한 정보가 손실될 수 있고 계산 부담도 증가시킨다. 청크 크기를 절반으로 줄이면 임베딩 벡터도 두 배가 된다. 최적 설정은 실험을 통해 찾아야 한다.

잘못된 예 — 문서를 겹침 없이 일정 크기로만 나누면 "I left my wife a note"가 "I left my wife"와 "a note"로 분할되어 두 청크 모두 원래 문장의 핵심 정보를 전달하지 못한다.

올바른 예 — 청크 크기 2,048자에 겹침 20자를 두어 경계 정보가 최소한 하나의 청크에 포함되도록 보장한다.

4.2 재순위화(Reranking)

검색기가 생성한 초기 문서 순위를 더 정확하게 다시 매기는 과정이다. 모델의 컨텍스트에 맞추거나 입력 토큰 수를 줄이기 위해 검색된 문서 수를 줄여야 할 때 특히 유용하다.

시간 기반 재순위화. 최신 데이터에 더 높은 가중치를 부여한다. 뉴스 수집, 주식 시장 분석 같은 시간에 민감한 애플리케이션에 유용하다.

컨텍스트 재순위화의 특수성. 일반 검색 재순위화와 달리, 문서가 포함되기만 한다면 그 순서가 미치는 영향은 검색 순위에 비해 상대적으로 덜 중요하다. 모델은 컨텍스트의 시작과 끝에 있는 문서를 더 잘 이해하는 경향이 있다.

4.3 질의 재작성(Query Rewriting)

질의 재구성, 질의 정규화, 또는 질의 확장이라고도 한다. 대화 맥락이 있는 경우 마지막 질의가 모호할 수 있다.

예시. 대화: - 사용자: "존 도가 마지막으로 우리에게서 무언가를 구매한 것은 언제인가요?" - AI: "존은 2030년 1월 3일, 2주 전에 마지막으로 과일 모자를 구매했습니다." - 사용자: "에밀리 도는 어떤가요?"

마지막 질의인 "에밀리 도는 어떤가요?"는 컨텍스트를 모른다면 모호하다. 이를 "에밀리 도가 마지막으로 우리에게서 무언가를 구매한 것은 언제인가요?"로 재작성해야 한다.

구현 방법. "다음 대화를 고려할 때, 사용자가 실제로 묻고 있는 내용을 반영하도록 마지막 사용자 입력을 재작성하세요" 같은 프롬프트로 다른 AI 모델을 사용해 질의를 재작성할 수 있다.

복잡한 경우. "그의 아내는 어떤가요?"처럼 신원 확인이나 다른 지식을 통합해야 하는 경우 더 복잡해질 수 있다. 정보가 없다면, 재작성 모델이 이름을 무작위로 지어내는 것보다 질의에 답할 수 없다고 명확히 알려야 한다.

4.4 컨텍스트 검색(Contextual Retrieval)

각 청크에 관련 컨텍스트를 추가해 필요한 청크를 더 쉽게 검색할 수 있게 하는 방식이다.

메타데이터 보강. 태그, 키워드, 제목, 캡션 같은 메타데이터로 청크를 보강한다. 특정 오류 코드(EADDRNOTAVAIL(99))가 있다면 메타데이터에 추가해두면 임베딩으로 변환된 후에도 키워드로 검색 가능하다.

질의 추가. 각 청크에 응답할 수 있는 질의들을 추가한다. 예: 비밀번호 재설정 문서에 "비밀번호를 어떻게 재설정하나요?", "로그인할 수 없어요" 등.

Anthropic의 컨텍스트 검색. AI 모델을 사용해 청크와 원본 문서의 관계를 설명하는 짧은 컨텍스트(보통 50~100토큰)를 생성하는 방식이다. 프롬프트:

<document>{{WHOLE_DOCUMENT}}</document>
여기에 전체 문서 내에서 위치시키고 싶은 청크가 있습니다:
<chunk>{{CHUNK_CONTENT}}</chunk>
청크의 검색을 개선하기 위해 이 청크를 전체 문서 내에서 위치시킬 수 있는
짧고 간결한 컨텍스트를 제공해 주세요. 간결한 컨텍스트만 응답하세요.

생성된 컨텍스트는 각 청크 앞에 추가되고, 보강된 청크는 검색 알고리즘에 의해 색인화된다. 이때 TF-IDF 색인과 임베딩 데이터베이스를 모두 활용하는 하이브리드 방식을 사용한다.

5. 텍스트를 넘어선 RAG — 멀티모달·표 형식 데이터

RAG의 외부 데이터 소스는 텍스트 문서만이 아니다.

5.1 멀티모달 RAG

생성 모델이 멀티모달 데이터를 처리할 수 있다면, 이미지·비디오·오디오 등도 컨텍스트로 활용할 수 있다.

이미지 검색. 이미지에 제목·태그·캡션 같은 메타데이터가 있다면 이 메타데이터를 사용해 검색한다. 이미지 내용을 기반으로 검색하려면 텍스트와 이미지를 모두 벡터로 변환할 수 있는 멀티모달 임베딩 모델이 필요하다. CLIP(Radford et al., 2021)이 대표적이다.

CLIP 활용 검색 과정: 1. 텍스트와 이미지를 포함한 모든 데이터의 CLIP 임베딩을 생성해 벡터 데이터베이스에 저장한다. 2. 질의에 대한 CLIP 임베딩을 생성한다. 3. 벡터 데이터베이스에서 질의 임베딩과 가장 유사한 이미지와 텍스트를 찾는다.

5.2 표 형식 데이터(Tabular Data) RAG

표에 담긴 정보가 필요한 질의에는 일반적인 RAG 워크플로와 상당히 다른 접근이 필요하다.

Text-to-SQL 흐름: 1. Text-to-SQL: 사용자 질의와 테이블 스키마를 기반으로 SQL 쿼리 결정(시맨틱 파싱의 한 예). 2. SQL 실행: 만들어진 SQL 쿼리를 실행. 3. 응답 생성: SQL 실행 결과와 사용자의 질의를 토대로 응답 생성.

사용 가능한 테이블이 너무 많아 모든 스키마를 컨텍스트에 담을 수 없다면, 각 질의에 어떤 테이블을 사용할지 예측하는 중간 단계가 필요하다. Text-to-SQL은 최종 응답 생성 모델로 수행하거나 특화된 별도 모델을 사용할 수 있다.

6. 에이전트 개요

에이전트는 자신의 환경을 인식하고 그 환경에서 행동할 수 있는 모든 것을 말한다(Russell & Norvig, 1995). 에이전트는 작동하는 환경과 수행할 수 있는 행동들로 정의된다.

환경의 다양성. 게임(마인크래프트, 도타)을 위한 에이전트라면 그 게임이 환경이 된다. 인터넷에서 문서를 수집하는 에이전트라면 인터넷이 환경이다. 요리 로봇의 경우 주방이, 자율주행 자동차의 경우 도로 시스템이 환경이다.

에이전트와 RAG의 관계. RAG 시스템은 검색기를 하나의 도구로 사용하는 특별한 형태의 에이전트다. 웹을 검색하고, 파이썬 코드를 실행하고, 이미지를 생성할 수 있는 챗봇도 에이전트다. 에이전트는 이 책에서 이미 다룬 모델의 자기 비평, CoT, 구조화된 출력 등을 토대로 만들어졌다.

에이전트가 더 강력한 모델을 필요로 하는 두 가지 이유. 첫째, 누적되는 오류다. 모델의 정확도가 단계당 95%라면 10단계 후에는 전체 정확도가 60%로 떨어지고 100단계 후에는 0.6%에 불과하다. 둘째, 더 큰 위험성이다. 도구에 접근할 수 있게 되면서 에이전트는 더 영향력 있는 작업을 수행할 수 있지만, 실패할 경우 더 심각한 결과를 초래할 수 있다.

코딩 에이전트 예시. SWE-agent(Yang et al., 2024)는 터미널과 파일 시스템이 있는 컴퓨터를 환경으로 사용하는 코딩 에이전트다. 에이전트가 할 수 있는 행동에는 저장소 탐색, 파일 검색, 파일 보기, 줄 편집 등이 포함된다.

주의 — AI 기반 에이전트는 아직 확립된 이론적 프레임워크가 없는 신생 분야다. 이 절은 기존 문헌을 바탕으로 프레임워크를 구축하려는 시도로, 분야의 발전과 함께 계속 변화할 것이다.

7. 도구 — 에이전트의 능력 확장

도구는 에이전트에게 환경을 인식하는 능력과 그 환경에 변화를 주는 능력을 부여한다. 에이전트가 접근할 수 있는 도구들의 집합을 도구 목록이라고 한다. 도구가 많을수록 에이전트의 능력은 향상되지만, 그만큼 이를 제대로 이해하고 효과적으로 활용하는 것이 더 어려워진다.

7.1 세 가지 도구 유형

지식 증강 도구. 에이전트의 지식을 증강해 주는 도구들이다. 텍스트 검색기(RAG), 이미지 검색기, SQL 실행기, 내부 인물 검색, 재고 API, 슬랙 메시지 검색, 이메일 읽기 도구 등이 있다. 웹 브라우징은 검색 API, 뉴스 API, 깃허브 API, 소셜 미디어 API 등 인터넷에 접근하는 모든 도구를 아우른다. 웹 브라우징은 모델이 구식이 되는 것을 막아준다. 그러나 인터넷의 유해한 콘텐츠에 노출될 위험도 있으므로 인터넷 API는 신중하게 선택해야 한다.

능력 확장 도구. AI 모델의 고유한 한계를 보완하는 도구들이다. 계산기(수학), 캘린더, 시간대 변환기, 단위 변환기, 번역기 등이 있다. 코드 인터프리터는 에이전트를 코딩 도우미, 데이터 분석가, 연구 조수 역할로 만들 수 있다. 외부 도구는 텍스트 전용 모델을 멀티모달로 만들 수 있다(예: 이미지 생성기, LaTeX 컴파일러, OCR 도구). 단, 자동 코드 실행에는 코드 주입 공격의 위험이 따르므로 적절한 보안 조치가 필수적이다.

쓰기 행동 도구. 에이전트가 환경에 직접 변화를 줄 수 있는 도구들이다. 이메일 발송, 데이터베이스 수정, 파일 시스템 조작, 은행 API 등이 있다. 고객 관리의 모든 단계(잠재 고객 조사, 연락처 찾기, 이메일 초안, 발송, 응답 읽기, 후속 조치, 주문 내역 추출)를 자동화할 수 있다. 그러나 AI에게 삶을 자동으로 변경할 수 있는 능력을 부여하는 것은 위험하다. 인턴에게 운영 환경 데이터베이스를 삭제할 권한을 주지 않는 것처럼, 신뢰할 수 없는 AI에 은행 송금 권한을 주어서는 안 된다.

7.2 도구 사용의 효과

Chameleon(Lu et al., 2023) 연구에서 13개의 도구로 보강된 에이전트가 여러 벤치마크에서 도구 없는 기반 모델 단독보다 뛰어난 성능을 보이는 것을 증명했다(논문 작성 당시 기반 모델로 사용한 모델은 해당 논문의 실험 환경 참조). ScienceQA에서 기존 최고 퓨샷 결과보다 11.37% 향상, TabMWP에서 정확도 17% 향상.

7.3 함수 호출(Function Calling)

많은 모델 제공업체가 함수 호출 기능을 지원한다. 작동 방식: 1. 도구 목록 생성: 실행 진입점(함수 이름), 파라미터, 문서(함수가 하는 일)로 구성. 2. 에이전트가 사용할 도구 지정: auto(자동), required(필수), none(미사용) 설정. 3. 모델이 어떤 도구를 사용할지, 필요한 파라미터를 자동으로 생성.

일부 함수 호출 API는 유효한 함수만 생성하도록 보장하지만, 파라미터 값까지 올바른지는 보장하지 못한다.

7.4 도구 선택 방법

도구 선택에는 실험과 분석이 필요하다. 방법: - 여러 도구 조합으로 에이전트 성능 비교. - 특정 도구를 제거했을 때 성능 저하 확인(제거 연구). - 에이전트가 자주 실수하는 도구를 찾아 교체. - 도구 호출 분포를 시각화해 사용 패턴 파악. - 자주 함께 사용되는 두 도구를 하나의 더 강력한 도구로 합치기(도구 전환 연구).

Voyager(Wang et al., 2023)는 에이전트가 습득한 새로운 기술(스킬)을 추적하고 재사용할 수 있게 해주는 스킬 매니저를 제안한다.

8. 계획 수립 — 에이전트의 두뇌

계획이란 작업을 달성하는 데 필요한 단계를 정리한 로드맵으로, 이를 만드는 과정이 계획 수립이다. 계획 수립은 본질적으로 탐색 문제다. 목표로 가는 다양한 경로를 탐색하고, 각 경로의 결과를 예측하며, 가장 유망한 결과를 가진 경로를 선택한다.

8.1 계획-검증-실행 분리

계획 수립과 실행을 같은 프롬프트에서 결합하면, 모델이 1,000단계 계획을 세워도 감독 없이 아무 성과 없이 API 호출 비용만 낭비할 수 있다. 이를 방지하기 위해 계획 수립과 실행을 분리해야 한다.

검증 방법. 유효하지 않은 행동이 포함된 계획을 제거하거나(예: 구글 검색 도구가 없는데 구글 검색을 포함한 계획), X단계 이상의 계획을 제거하거나, AI 평가자를 사용해 계획의 합리성을 평가한다.

멀티 에이전트 구조. 계획을 생성하는 요소, 검증하는 요소, 실행하는 요소를 분리하면 각 구성 요소를 에이전트로 볼 수 있어 멀티 에이전트 시스템이 된다. 병렬로 여러 계획을 동시에 만들고 평가자에게 가장 최적의 계획을 선택하도록 할 수도 있다.

사람 개입(Human-in-the-Loop). 복잡한 작업의 경우 전문가가 계획의 큰 틀을 제공하고 에이전트가 구체화할 수 있다. 데이터베이스 업데이트나 코드 변경 같이 위험한 작업이 포함된 경우, 실행 전 사용자의 명시적 승인을 요청하거나 사람이 직접 실행하도록 할 수 있다.

8.2 계획 생성

프롬프트 엔지니어링. 모델을 계획 생성기로 만드는 가장 간단한 방법이다. 가능한 행동 목록, 예시(작업-계획 쌍)를 포함한 시스템 프롬프트를 작성한다.

계획의 세부성(Granularity). 세부적인 계획은 생성하기 어렵지만 실행하기 쉽다. 큰 틀의 계획은 생성하기 쉽지만 실행하기 어렵다. 계층적 계획 수립으로 이 절충을 피할 수 있다(큰 그림 계획 먼저, 각 단계마다 세부 계획 수립).

자연어 계획. 정확한 함수 이름 대신 자연어로 계획을 작성하면 도구 API 변화에 더 유연하게 대응할 수 있다. 단, 자연어 행동을 실행 가능한 명령으로 번역하는 번역기가 필요하다(번역은 계획 수립보다 훨씬 간단한 작업).

계획 개선 방법. 더 나은 시스템 프롬프트 작성, 도구와 파라미터 상세 설명, 함수를 더 단순하게 분리, 더 강력한 모델 사용, 계획 생성을 위한 파인튜닝.

8.3 제어 흐름(Control Flow)

행동이 실행되는 순서를 제어 흐름이라고 한다.

• 순차 실행 — 작업 A가 끝난 후 작업 B 실행. 예: SQL 질의 변환 후 실행.
• 병렬 실행 — 작업 A와 B를 동시에 실행. 예: 베스트셀러 100개 제품의 가격을 동시에 조회. 사용자가 체감하는 지연 시간을 크게 줄인다.
• If 조건문 — 이전 단계 결과에 따라 분기. 예: 실적 보고서 결과에 따라 주식 매수·매도 결정.
• For 반복문 — 특정 조건이 충족될 때까지 반복. 예: 소수가 나올 때까지 무작위 숫자 생성.

에이전트 프레임워크를 평가할 때는 어떤 제어 흐름을 지원하는지 확인하는 것이 중요하다.

8.4 ReAct 프레임워크

ReAct(Yao et al., 2022)에서 처음 제안한 추론(Reasoning)과 행동(Acting)의 교차 방식은 에이전트의 일반적인 패턴이 되었다. 각 단계에서 에이전트는 생각을 설명하고(계획), 행동을 취한 다음, 관찰 결과를 분석(성찰)하는 과정을 반복하며, 작업이 완료됐다고 판단할 때까지 계속된다.

생각 1: [현재 상황 분석 및 다음 행동 추론]
행동 1: [도구 호출]
관찰 1: [도구 출력 결과]
...
생각 N: [작업 완료 판단]
행동 N: 완료 [최종 응답]

8.5 성찰(Reflexion)과 오류 수정

성찰은 에이전트가 각 단계 후 자기 평가를 수행해 오류를 감지하고 계획을 수정하는 메커니즘이다. 에이전트 작동에 반드시 필요한 것은 아니지만, 성능을 크게 향상시킨다.

성찰이 유용한 단계. 사용자 질의를 받은 후(실현 가능성 검토), 초기 계획 수립 후(타당성 확인), 각 실행 단계 이후(올바른 방향 점검), 전체 계획 실행 후(작업 완료 확인).

Reflexion 프레임워크(Shinn et al., 2023). 성찰이 두 모듈로 나뉜다. 결과를 평가하는 평가자와 무엇이 잘못됐는지 되짚어보는 성찰 모듈이다. 각 단계에서 평가와 성찰 후 에이전트는 새로운 궤적(trajectory)을 제안한다.

성찰의 장단점. 상대적으로 구현하기 쉽고 성능 향상이 크다. 단, 지연 시간과 비용이 늘어나는 단점이 있다. 특히 중간 단계가 많은 작업에서는 비용과 지연 시간이 증가한다.

8.6 파운데이션 모델의 계획 수립 능력

LLM의 계획 수립 능력에 대한 논쟁이 있다. Kambhampati(2023)는 LLM이 지식 추출에는 뛰어나지만 계획 수립에는 그렇지 않다고 주장했다. 반면 Hao et al.(2023)은 LLM이 세계에 대한 방대한 정보를 담고 있어 각 행동의 결과를 예측할 수 있다고 주장한다.

자기회귀 모델이 앞으로만 나아간다는 한계(백트래킹 불가)도 논의되지만, A 행동 경로 실행 후 적절하지 않다고 판단하면 B 행동으로 경로를 수정할 수 있어 사실상 백트래킹과 같다. LLM이 완벽하게 계획을 세울 수 없더라도, 검색 도구와 상태 추적 시스템을 결합하면 계획 수립 능력을 강화할 수 있다.

FM 에이전트 vs RL 에이전트. RL 에이전트는 강화 학습 알고리즘을 통해 계획 능력을 학습하는데 상당한 시간과 자원이 필요하다. FM 에이전트는 모델 자체가 계획 수립자 역할을 하며 프롬프트나 파인튜닝으로 능력을 향상시킬 수 있어 더 적은 시간과 자원으로 가능하다. 장기적으로 FM 에이전트와 RL 에이전트는 결국 통합될 것으로 예상된다.

9. 에이전트 실패 유형과 평가

평가란 실패를 발견하는 과정이다. 에이전트가 수행하는 작업이 복잡할수록 실패 가능성도 더 많아진다. 에이전트는 계획 수립, 도구 실행, 효율성과 관련된 실패를 겪는다.

9.1 계획 수립 실패

도구 사용 실패 3가지 유형. 1. 유효하지 않은 도구 — 도구 목록에 없는 함수(예: bing_search)를 포함한 계획 생성. 2. 유효한 도구, 유효하지 않은 파라미터 — lbs_to_kg를 파라미터 두 개로 호출(하나만 필요). 3. 유효한 도구, 잘못된 파라미터 값 — lbs_to_kg(lbs=100)이어야 하는데 lbs_to_kg(lbs=120) 사용.

목표 달성 실패. 제약 조건을 따르지 않거나, 요청한 목적지가 아닌 다른 곳으로의 여행을 계획하는 경우.

성찰 오류. 에이전트가 실제로는 작업을 완료하지 못했는데도 완료했다고 확신하는 것. 예: 50명을 30개 객실에 배정해달라고 했는데 40명만 배정하고 완료됐다고 하는 경우.

시간 제약. 에이전트 평가 시 종종 간과되는 중요한 제약 조건이다. 보조금 신청서를 준비해달라고 했는데 마감일이 지나서야 끝낸다면 결과물은 아무 쓸모가 없다.

평가 데이터셋. (작업, 도구 목록) 쌍으로 구성된 계획 수립 데이터셋을 만들어 K개의 계획을 생성하고 유효한 계획 비율, 유효한 계획을 얻기 위한 평균 시도 횟수, 도구 호출 유효 비율, 실패 유형별 빈도를 계산한다.

9.2 도구 실패

올바른 도구를 사용했지만 그 결과가 잘못된 경우다. 도구 자체가 잘못된 출력을 내놓거나(이미지 캡션 생성기가 잘못된 설명 제공), 자연어 계획을 실행 명령으로 번역하는 과정에서 오류가 발생하거나, 에이전트가 필요한 도구를 갖고 있지 않을 때 발생한다.

각 도구는 개별적으로 테스트되어야 한다. 항상 모든 도구 호출과 그 결과를 출력하여 검사하고 평가할 수 있도록 해야 한다.

9.3 효율성 지표

• 작업 완료에 평균 몇 단계가 필요한가?
• 작업 완료에 평균 얼마의 비용이 드는가?
• 각 행동에 보통 얼마나 시간이 걸리는가?

AI 에이전트와 사람을 비교할 때는 둘의 작동 방식이 매우 다르다는 점을 고려해야 한다. 100개의 웹 페이지를 방문하는 일은 사람에게는 큰 부담이지만 AI 에이전트에게는 간단한 작업일 수 있다.

에이전트 벤치마크: 버클리 함수 호출 리더보드, AgentOps 평가 도구, TravelPlanner 벤치마크.

10. 메모리 시스템

메모리는 모델이 정보를 저장하고 활용할 수 있게 하는 방식이다. RAG와 에이전트 모두 방대한 양의 정보를 다루며, 이는 종종 파운데이션 모델의 최대 컨텍스트 길이를 초과한다.

10.1 세 가지 메모리 계층

내부 지식. 모델이 학습한 데이터에서 얻은 지식이 모델 가중치에 저장된다. 모델이 업데이트되지 않는 한 변하지 않는다. 모든 질의에서 접근 가능하다.

단기 메모리. 모델의 컨텍스트 윈도우가 단기 메모리 역할을 한다. 이전 대화 내용을 컨텍스트에 추가하면 모델이 다음 응답 생성 시 이 정보를 활용한다. 작업이 끝나면 사라지므로 단기 메모리다. 접근 속도는 빠르지만 용량이 한정되어 있다.

장기 메모리. RAG 시스템처럼 외부 데이터 소스에서 검색을 통해 접근한다. 작업이 끝나도 유지되므로 장기 메모리다. 모델의 내부 지식과 달리, 정보를 모델 자체를 업데이트하지 않고도 수정하거나 삭제할 수 있다.

정보 배치 기준. 모든 작업에 필수적인 정보는 파인튜닝으로 내부 지식화. 거의 필요하지 않은 정보는 장기 메모리. 현재 진행 중인 작업에 바로 필요한 정보는 단기 메모리.

10.2 메모리 시스템의 이점

• 세션 내 정보 과부하 관리 — 에이전트가 얻은 새로운 정보가 최대 컨텍스트 길이를 초과하면 장기 메모리에 저장.
• 세션 간 정보 유지 — 사용자 취향·대화 기록을 유지해 맞춤화된 서비스 제공.
• 모델의 일관성 향상 — 이전 응답을 참조해 향후 응답의 일관성 유지.
• 데이터 구조 무결성 유지 — 구조화된 데이터(예: 잠재 고객 목록을 엑셀 시트)를 적절히 저장.

10.3 메모리 관리 전략

메모리 관리는 메모리 추가와 삭제라는 두 가지 작업으로 이루어진다. 단기 메모리는 모델의 최대 컨텍스트 길이에 의해 제한되므로 전략이 필요하다.

FIFO(선입선출). 단기 메모리에 가장 먼저 추가된 정보가 가장 먼저 외부 저장소로 이동한다. 구현이 쉽지만, 초기 메시지에 대화의 목적이 명시되어 있을 경우 중요한 정보를 놓칠 위험이 있다.

중복 제거. 대화의 요약을 생성해 메모리 사용량을 줄인다. Bae 등(2022)은 요약에서 놓친 핵심 정보와 기존 메모리를 결합해 새로운 메모리를 구성하는 분류기를 개발했다.

성찰 기반 접근법. Liu 등(2023)은 각 행동 후 에이전트에게 새로운 정보가 메모리에 추가되어야 하는지, 기존 메모리와 병합되어야 하는지, 또는 다른 정보로 대체해야 하는지 결정하도록 요청한다.

컨텍스트 배분. 컨텍스트의 30%가 장기 메모리 정보를 위해 예약되어 있다면, 모델은 단기 메모리의 최대 70%까지만 사용할 수 있다. 이 한계에 도달하면 넘치는 정보는 장기 메모리로 이동한다.

핵심 개념 정리

실무 체크리스트

RAG 시스템을 구축하고 에이전트를 운영할 때 점검할 것:

• [ ] 데이터 규모와 업데이트 주기에 맞는 검색 알고리즘(용어 기반 / 임베딩 기반 / 하이브리드)을 선택했는가?
• [ ] 청크 크기와 겹침 범위를 여러 값으로 실험해 최적 설정을 찾았는가?
• [ ] 대화형 애플리케이션에서 질의 재작성을 적용해 이전 맥락을 반영했는가?
• [ ] 컨텍스트 정밀도와 컨텍스트 재현율을 측정했는가?
• [ ] 임베딩 기반 검색을 사용한다면 MTEB 벤치마크 등으로 임베딩 품질을 평가했는가?
• [ ] 벡터 데이터베이스의 확장성·지연 시간·가격 체계를 검토했는가?
• [ ] 에이전트가 사용할 도구 목록이 작업과 환경에 적합하게 선택됐는가?
• [ ] 각 도구를 개별적으로 테스트했는가?
• [ ] 에이전트의 계획 수립 실패(유효하지 않은 도구, 잘못된 파라미터, 목표 달성 실패) 빈도를 측정하고 있는가?
• [ ] 성찰 메커니즘을 도입해 에이전트가 오류를 감지하고 수정할 수 있게 했는가?
• [ ] 단기·장기 메모리 관리 전략이 세션 내 정보 과부하와 세션 간 정보 유지를 모두 고려했는가?
• [ ] 에이전트의 자동화 수준에 비례해 보안 메커니즘(특히 쓰기 행동 도구)을 갖추었는가?
• [ ] 에이전트 프레임워크가 필요한 제어 흐름(병렬·조건문·반복문)을 지원하는가?

연습문제

1. 개념. RAG가 롱 컨텍스트로 완전히 대체될 수 없는 두 가지 이유를 설명하라. Anthropic이 제시한 실용적 임계값은 무엇인가?

2. 비교. "트랜스포머 아키텍처"라는 질의에 대해 용어 기반 검색과 임베딩 기반 검색이 각각 어떤 문서를 검색할 가능성이 높은지 비교하라. 어느 방법이 더 적합한가? 키워드 검색이 더 유리한 반대 사례도 들어라.

3. 적용. 문서가 1,000만 개 이상인 대형 지식 베이스를 구축한다고 할 때, 청킹 전략과 벡터 검색 알고리즘을 어떻게 설계하겠는가? 청크 크기, 겹침, 분할 방식, ANN 알고리즘 선택 기준을 설명하라.

4. 분석. 에이전트의 정확도가 단계당 90%라면 15단계 작업의 최종 정확도는 얼마인가? 이 수치가 에이전트 설계에 주는 시사점은 무엇인가? 성찰 메커니즘은 이 문제를 어떻게 완화하는가?

5. 설계. 고객 지원 에이전트를 설계한다고 할 때, ReAct 프레임워크와 성찰 메커니즘을 적용해 "환불을 요청하고 싶은데 어떻게 하나요?"라는 질의를 처리하는 흐름을 단계별로 설명하라. 발생 가능한 에이전트 실패 유형과 그 대처 방법도 포함하라.

최신 동향 (2026-05 기준)

최신 동향 (검증 2026-05-21) — RAG·에이전트는 변화가 가장 빠른 영역이다. 단순(Naive) RAG는 더 이상 production 표준이 아니며, Agentic RAG(에이전트가 검색을 반복 판단)·GraphRAG(지식 그래프 기반 RAG로 마이크로소프트 공개)가 baseline으로 자리잡았다. LangGraph 같은 에이전트 프레임워크가 순환 그래프 구조로 복잡한 에이전트 워크플로를 지원하며 널리 쓰인다. 에이전트 설계 패턴의 구체적 가이드는 Building Effective Agents 참조.

부록 A. 용어 사전

부록 B. 핵심 비교표

비교 1. 검색 방식 3가지

비교 2. RAG와 에이전트의 역할 분담

비교 3. 에이전트 메모리 계층

비교 4. ANN 알고리즘 비교

부록 C. 추천 참고 자료

검증된 외부 자료 (생존 확인 2026-05-21)

이 책 관련 장

• 책 3장 — 임베딩의 원리와 품질 평가 방법. 임베딩 기반 검색의 핵심 기반. MTEB 벤치마크 상세 설명.
• 책 5장 — 프롬프트 엔지니어링과 CoT. 에이전트 계획 수립의 기반 기법. 방어적 프롬프트 엔지니어링과 보안.
• 책 7장 — 파인튜닝. RAG 시스템 전체 파인튜닝, 도구 사용 파인튜닝.

핵심 논문

• Chen et al. (2017) — Reading Wikipedia to Answer Open-Domain Questions. 검색 후 생성 패턴 최초 소개.
• Lewis et al. (2020) — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. RAG 패턴 최초 체계화. 검색기와 생성 모델의 공동 학습 구조.
• Yao et al. (2022) — ReAct: Synergizing Reasoning and Acting in Language Models. 생각-행동-관찰 반복 구조 정의.
• Shinn et al. (2023) — Reflexion: Language Agents with Verbal Reinforcement Learning. 성찰 기반 자기 수정 메커니즘 제안.
• Lu et al. (2023) — Chameleon: Plug-and-Play Compositional Reasoning. 도구 사용의 효과를 ScienceQA·TabMWP에서 실증.
• Hao et al. (2023) — Reasoning with Language Model is Planning with World Model. LLM의 계획 수립 능력에 대한 세계 모델 관점.
• Yang et al. (2024) — SWE-agent. 터미널·파일 시스템 환경 코딩 에이전트 구현 사례.

공식 문서 및 가이드

• Anthropic — 컨텍스트 검색(Contextual Retrieval) 블로그. 청크에 AI 생성 컨텍스트를 추가해 검색 정확도를 높이는 방법.
• 엘라스틱서치 공식 문서 — BM25 알고리즘 설명 및 하이브리드 검색 구성 예시.
• FAISS GitHub (Facebook AI) — ANN 인덱스 구조·성능 벤치마크. 수백만 벡터 운영 시 참조.
• ANN-벤치마크 웹사이트 — 재현율·QPS·구축 시간·색인 크기 4가지 지표로 ANN 알고리즘 비교.

부록 D. 연습문제 풀이

1. (데이터 증가 + 롱 컨텍스트 활용 한계) 첫째, 데이터는 계속 증가하기 때문에 컨텍스트 길이가 아무리 늘어도 그보다 더 긴 컨텍스트가 필요한 애플리케이션이 생길 수밖에 없다(파킨슨의 법칙 유비). 둘째, 롱 컨텍스트를 처리할 수 있는 모델이 반드시 그 컨텍스트를 잘 활용하는 것은 아니다 — 컨텍스트가 길수록 잘못된 부분에 집중할 가능성이 높아지고 비용과 지연 시간이 증가한다. Anthropic이 제시한 실용적 임계값은 200,000토큰(약 500페이지 분량)이다. 이보다 작으면 RAG 없이 전체 지식 베이스를 프롬프트에 포함해도 된다.

2. (임베딩 기반 검색이 더 적합; 키워드 반례) 용어 기반 검색(BM25)은 "트랜스포머"라는 단어가 포함된 문서를 우선 반환하므로, 전기 장치나 영화 트랜스포머 관련 문서가 혼입될 수 있다. 임베딩 기반 검색은 의미 벡터 유사도를 기준으로 하므로 AI 모델 관련 문서를 더 정확하게 검색한다. 단, 특정 오류 코드(EADDRNOTAVAIL(99)) 검색처럼 정확한 키워드 매칭이 필요한 경우에는 용어 기반이 더 유리하다. 임베딩 기반에서는 오류 코드가 의미 벡터로 변환되면서 희석될 수 있다.

3. (대형 지식 베이스 청킹 + 벡터 검색 설계) 청크 크기는 실험을 통해 최적 설정을 찾되, 재귀적 분할을 우선 적용하고 겹침(예: 청크 크기의 10% 내외)을 둔다. 청크 크기를 절반으로 줄이면 임베딩 벡터 수도 두 배가 되므로 비용·속도 트레이드오프를 고려한다. 벡터 검색은 k-NN 대신 ANN 알고리즘(HNSW가 높은 정확도와 빠른 검색 균형 면에서 일반적으로 권장)을 사용한다. ANN-벤치마크 기준으로 재현율·QPS·구축 시간·색인 크기를 비교해 환경에 맞게 선택한다. 운영 환경에서는 용어 기반으로 후보를 먼저 추려낸 뒤 임베딩 기반으로 재순위화하는 하이브리드 방식을 권장한다.

4. (약 20.6%, 단계 수 최소화·강력한 모델·성찰 도입) 정확도 0.9의 15승은 약 0.206(20.6%)이다. 이 수치가 에이전트 설계에 주는 시사점은 두 가지다: 첫째, 단계 수를 최대한 줄이는 것이 전체 정확도를 지키는 핵심이다. 둘째, 더 정확한(강력한) 모델을 사용해야 한다. 성찰 메커니즘은 각 단계 후 자기 평가를 수행해 오류를 조기에 감지하고 수정함으로써 누적 오차를 줄여준다. 성찰은 구현하기 상대적으로 쉽고 성능 향상이 크지만, 지연 시간과 비용이 늘어나는 단점이 있다.

5. (ReAct + 성찰 기반 고객 지원 에이전트 흐름) 질의 수신 후 에이전트는 먼저 생각 단계에서 "환불 요청이므로 고객 주문 이력과 환불 정책을 조회해야 한다"고 추론한다. 행동 단계에서 지식 증강 도구(RAG 또는 내부 DB 검색)로 환불 정책 문서를 검색하고, 능력 확장 도구(주문 조회 API)로 고객 주문 이력을 확인한다. 관찰 단계에서 결과를 수신한 뒤 성찰 모듈이 "정책 요건이 충족됐는가, 응답이 완전한가"를 자기 평가한다. 요건이 충족됐다면 쓰기 행동 도구(환불 처리 API 또는 담당자 이메일 발송)를 호출하고 최종 응답을 반환한다. 발생 가능한 실패 유형: 유효하지 않은 도구 호출(계획 수립 실패), 주문 조회 API 오류(도구 실패), 성찰 오류(부분 환불만 처리하고 완료됐다고 판단). 대처: 도구 호출과 결과를 항상 로그로 출력해 평가하고, 성찰 메커니즘으로 부분 완료 감지 후 추가 처리 단계를 실행한다.